Fix diffing of relocations to symbols that have compiler-generated names - #381
Conversation
|
There is an issue with this change I noticed though, that if a compiler-generated float literal like Maybe ignoring literal address should be a new config option so that it's possible to disable this change? Or alternatively if objdiff supported order and alignment diffing, it wouldn't need to check the address to know if the literals are in the wrong place and show a diff. |
This fixes a bug where "Name or address" comparison wouldn't detect relocations to symbols like name$1234 and name$2345 as being the same if they were at different addresses.
ef46b02 to
ad47719
Compare
|
Now that objdiff can diff symbol order (#385) as well as show symbol alignment (#384), I think the issue with this fix I mentioned in my previous comment shouldn't be a problem in practice anymore, as there are better ways to find out if literals are in the wrong place than relying on their exact address. |
1 participant
Fixes two bugs when diffing relocations, which were treated inconsistently by different parts of objdiff:
symbol$1234andsymbol$2345) are now normalized for relocation diffing. (This was already done when diffing data and when pairing up symbols.)@1234and@2345) are now ignored for relocation diffing. (This was already done when pairing up symbols.)In practice this means that "Name or address" mode can now be used more reliably even in TUs with stripped data that causes the addresses to not match up (which is common in projects that use precompiled headers like TWW/TP). Prior to these fixes real name diffs were hard to spot because they could get mixed up in dozens of fake
@1234vs@2345diffs. And if you use "Data value" mode they don't show up at all.Before:
After:
It also fixes RTTI data sometimes showing as nonmatching because it contains relocations to compiler-generated symbols.
Before:
After: